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REPLY BRIEF 



Applicants submit this Reply Brief to the Board of Patent Appeals and 
Interferences in response to Examiner's Answer dated June 5, 2008. While Applicants 
maintain each of the arguments submitted in Applicants' previously submitted Appeal 
Brief, Applicants make the following further arguments in light of the Examiner's 
Answer. Please charge any additional fees that may be required to make this Reply 
Brief timely and acceptable to Deposit Account No. 09-0465/ ROC920030407US1 . 
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ARGUMENTS 

The Examiner continues to suggest that the combination of Sandler and 

Kaufman discloses the method recited by claim 1 "for identifying correlated columns 

from database tables" that includes: 

determining correlation attributes for a first column and a second column 
from one or more database tables, the correlation attributes describing for 
each column at least one of the column and content of the column; . . . 
upon determining the first and second columns are correlated, merging 
the first and second columns to create a third column that contains each 
data value stored in the first and second columns; and 
storing the third column in the database. 

Claims 22 and 43 recite a similar limitation. The Examiner continues to point to a 

description in Sandler of values from a table being added together to suggest 

that this reference discloses "determining correlation attributes for a first column 

and a second column" as well as "merging the first and second columns to create 

a third column that contains each data value stored in the first and second 

columns." Specifically, the Examiner cites to a table illustrated in Sandler, Figure 

18A with the following values: 



TableTI 




(Figure 18, 1800) 


F1 


K1 


A 


1 


A 


2 


B 


3 


K 


4 


B 


5 



Table Target 
(Figure 18, 1802) 


F1 


K1 


A 


3 


B 


8 


K 


4 



In this example, as part of an "aggregation operation" disclosed in Sandler, the repeated 
"A" values of "1" and "2" in Table T1 are summed to create an entry of "A" with a value 
of "3". Similarly, the repeated "B" values of "3" and "5" in Table T1 are summed to 
create an entry of "B" with a value of "8." Clearly, the process of simply summing up the 
numerical values in the K1 column, based on repeating values in the F1 column, does 
not disclose the claimed step of "determining correlation attributes for a first column and 
a second column from one or more database tables," as suggested by the Examiner. 
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Moreover, claim 1 (and claims 22 and 43) goes on to recite, a step performed 
directly in response to determining that two columns are "correlated"; namely, upon 
determining the first and second columns are correlated, the first and second columns 
are merged to create a third column that contains each data value stored in the first and 
second columns. That is, as claimed, the merging occurs in direct response to a 
determination that at least two columns are correlated, and in direct response, the data 
values are stored in a third column . Nevertheless the Examiner points to the same 
passages where values from a single column are added together , not merged to create 
a third column. Applicants submit that these operations are plainly distinct from one 
another. Perhaps recognizing this, the Examiner now also cites to an example of a 
"fuse" operation described in Sandler. As disclosed in Sandler, a "fuse" operation may 
be used to join two tables together (in the language of SQL, a "fuse" operation may be 
performed using the well known operation of a full outer join). In this process, no third 
column is created by the table join. Instead, each column present in two tables being 
joined is present in the third table, no new columns are created. 

More importantly, however, nothing in the description of the "fuse" operation 

corresponds to the relationship between limitations recited by the present claims. 

Specifically, nothing in the passages from Sandler describing certain entries from one 

table being added together (i.e., and "aggregation operation") or the "fuse" operation 

("i.e., a full-outer join between two tables) disclose anything being performed in 

response to determining that two columns are "correlated"; namely, nothing in these 

table operations disclose the claimed steps recited by claims 1 , 22, and 43 of: 

determining correlation attributes for a first column and a second column 
from one or more database tables, the correlation attributes describing for 
each column at least one of the column and content of the column; 
comparing the correlation attributes from the first and second column; 
identifying similarities between the first and second column on the basis of 
the comparison. 

Finally, the Examiner also attempts to sustain the present rejection by citing to 
Kaufman, Figure 5B, et seq., reproduced below: 
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Plainly, this figure depicts a relational database schema for three tables. The general 
content of these tables is discussed at Kaufman, 134-139. Specifically, Kaufman 
indicates that this schema represents a "reference implementation" for the invention 
disclosed in Kaufman that includes six tables (including the three tables shown in Figure 
5B). As disclosed, the reference implementation includes a first table 
"SECURITY_GROUP_USER" having the seven listed columns, a second table named 
"PEOPLE," and a third table "USERS." As described in Kaufman, the "USERS" table 
includes a "USERS_KEY" column and a "PEOPLE_KEY" column used as a foreign key 
into the "SECURITY_GROUP_USER" table and the "PEOPLE" table. As is well known, 
a "foreign key," is a reference in one table to a key in another table, meaning that the 
referencing table has a column that may be used to store values of a primary key in 
another table. 

This example of a relational schema of these three tables has no apparent 

relevance to using "correlation attributes for a first column and a second column" to 

identify "similarities between the first and second column" and "upon determining the 

first and second columns are correlated, merging the first and second columns to create 

a third column that contains each data value stored in the first and second columns," as 

claimed. Instead this material provides a particular relational schema used by the 

invention disclosed in Kaufman. Nevertheless the Examiner suggests: 

Fig 5B, wherein the column "SECURITY_GROUP_USER" corresponds to 
the first column claimed, the column "PEOPLE" corresponds to the second 
column claimed, and wherein the "USERS" column corresponds to the 
third column claimed, also note that the "USERS" column contains each 
data value stored in the first and second column, such as "USERS_KEY" 
and "PEOPLE KEY." ... The "USERS" incorporates (among others) 
LoginJD field, which is correlated against the system-user's operating 
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environment credentials. (In the reference implementation this is the UID 
which has been authenticated and forwarded by the web server; 
alternatively it could be the user's OS login.) When the system 
establishes a new user-session (upon the user's initial contact), it attempts 
this correlation to a valid USERS. LoginJD. If no correlation can be 
made", Kaufman. ... Examiner also notes that ... the Kaufman reference 
was presented for the purpose of: "the third column contains each data 
value stored in the first and second columns." 

Examiner's Answer, p. 21 . Applicants respectfully submit that the Examiner is simply 

mistaken in suggesting that "'SECURITY_GROUP_USER' corresponds to the first 

column claimed," as "SECURITY_GROUP_USER" does not refer to a column, it refers 

to a table . See e.g., Kaufman, 133, 134 ("In the reference implementation, six tables 

support these security features: ... SECURITY_GROUP_USERS ..."). 

Similarly, the Examiner errs in suggesting that "the column "PEOPLE" 

corresponds to the second column claimed, and wherein the "USERS" column 

corresponds to the third column claimed," as both "PEOPLE" and "USERS" refer to 

tables . For example, Kaufman describes these constructs as: 

[0135] The PEOPLE table contains an Active_Flag field, which allows for 
"deactivation" of individuals without destroying existing Rl links throughout 
the database. ... 

[0136] The USERS table incorporates (among others) a LoginJD field, 
which is correlated against the system-user's operating-environment 
credentials. ... 

Kaufman, fflj 135, 136. Furthering this misconception, the Examiner goes on to suggest 
that that "the 'USERS' column contains each data value stored in the first and second 
column , such as 'USERSKEY' and 'PEOPLEKEY'." Plainly, the USERS "column- 
does not contain "each data value stored in the first and second column," as suggested 
by the Examiner. Among others things, the "PEOPLE" table includes an "Active_Flag 
field" which is not included in the "USERS" table . That is, the "USERS" table includes a 
"USERS KEY" column and "PEOPLE KEY" column as keys into the other two tables, 
but plainly does not include the values of other columns f rom these other two tables. 

For all the foregoing reasons, Applicants submit that the present rejection fails to 
demonstrate that claim 1 , 22, and 43 are not patentable over Sandler in view of 
Kaufman. Further, regarding claims 2 and 23; claims 9, 1 1 , 14, 30, 34, and 35, claims 
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3-6, 7-8, 10, 12-13, 15-16, 24-27, 28-29, 31-33, and 36-37; claims 17, 38, and 44; and 
claims 18-21 and 39-42, Applicants believe the Arguments set forth in Applicants' 
Appeal Brief demonstrate the patentability of these claims over Sandler in view of 
Kaufman. 
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CONCLUSION 



The Examiner errs in finding that claims 1-44 are unpatentable over Sandler in 
view of Kaufman under 35 U.S.C. § 103(a). 



Withdrawal of the rejections and allowance of all claims is respectfully requested. 



Respectfully submitted, and 
S-signed pursuant to 37 CFR 1.4, 

/Gero G. McClellan, Reg. No. 44,227/ 



Gero G. McClellan 
Registration No. 44,227 
Patterson & Sheridan, L.L.P. 
3040 Post Oak Blvd. Suite 1500 
Houston, TX 77056 
Telephone: (713)623-4844 
Facsimile: (713)623-4846 
Attorney for Appellant(s) 
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